Repository navigation
[Aikido] Fix IDOR protection bypass by validating tenant equality clause context - #437
Closed
aikido-autofix[bot] wants to merge 1 commit into
Closed
aikido-autofix[bot] wants to merge 1 commit into
aikido-autofix[bot] wants to merge 1 commit into
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch addresses an IDOR (Insecure Direct Object Reference) protection bypass vulnerability where tenant equality checks were not validated for their SQL clause context. Attackers could bypass tenant isolation by placing tenant column equalities in non-filtering contexts such as SELECT projections or HAVING clauses. The fix adds clause context validation to
lib/aikido/zen/idor/analysis_result.rbandlib/aikido/zen/idor/protector.rb, ensuring tenant equalities are only accepted when originating from WHERE clauses. This strengthens row-level security enforcement and prevents unauthorized data access across tenant boundaries.✅ 1 issue fixed by this PR
SelectVisitor::pre_visit_exprtraverses expressions across a SELECT and records equality expressions without preserving whether they originated in a row-restricting WHERE clause, a projection, HAVING, JOIN condition, or a negated predicate.Protector#protect_filterthen accepts any matching tenant column whose resolved value equals the request tenant ID. For example, with tenant ID 1 bound to$1,SELECT tenant_id = $1 AS same_tenant, users.* FROM usersemits tenant equality metadata even though the equality is only a per-row projected boolean; it does not restrict the result set. The protector consequently allows the query, which can return rows belonging to every tenant. The demonstrated impact is a cross-tenant read; the supplied evidence does not independently establish mutation bypasses.